Re: Funny issue with casting double to ulong
On Mon, Jul 03, 2017 at 05:38:56AM +, Era Scarecrow via Digitalmars-d-learn wrote: > On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: > > 6.251 has no perfect double representation. It's real value is: > > I almost wonder if a BCD, fixed length or alternative for floating > point should be an option... Either library, or a hook to change how > the FPU works since doubles are suppose to do 16-18 digits of perfect > simple floatingpoint for the purposes of money and the like without > relying on such imperfect transitions. >From what I've heard, word on the street is to avoid using floating-point for money calculations, and use fixed-point arithmetic instead (i.e., basically ints / longs, with a built-in decimal point in a fixed position). Inexact representations of certain fractions of tens like the above are one reason for this. I don't think there's a way to change how the FPU works -- the hardware is coded that way and can't be changed. You'd have to build your own library or use an existing one for this purpose. T -- Food and laptops don't mix.
Re: Funny issue with casting double to ulong
On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: 6.251 has no perfect double representation. It's real value is: I almost wonder if a BCD, fixed length or alternative for floating point should be an option... Either library, or a hook to change how the FPU works since doubles are suppose to do 16-18 digits of perfect simple floatingpoint for the purposes of money and the like without relying on such imperfect transitions.
Re: Funny issue with casting double to ulong
On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote: [...] 6.251 has no perfect double representation. It's real value is: 6.215099962483343551867E0 Hence when you cast to ulong after the product by 10_000, this is the equivalent of trunc(62150.99962483343551867E0) which gives 62150 CQFD ;-] That explains it! Thank you.
Re: Funny issue with casting double to ulong
On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote:
Consider this snippet:
void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);
auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}
The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151
Why does c round off from 62151 to 62150 when casting to ulong?
Thanks,
Saurabh
6.251 has no perfect double representation. It's real value is:
6.215099962483343551867E0
Hence when you cast to ulong after the product by 10_000, this is
the equivalent of
trunc(62150.99962483343551867E0)
which gives 62150
CQFD ;-]
Funny issue with casting double to ulong
Consider this snippet:
void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);
auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}
The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151
Why does c round off from 62151 to 62150 when casting to ulong?
Thanks,
Saurabh
Re: Bulk allocation and partial deallocation for tree data structures.
On Monday, 3 July 2017 at 02:51:49 UTC, Filip Bystricky wrote: Anyone? The answer is no. Partial deallocation in an arbitrary fashion is not advisable. And there are no standard library mechanisms for it.
Re: Bulk allocation and partial deallocation for tree data structures.
Anyone?
Re: std.string.format call from varyargs
On Sun, Jul 02, 2017 at 11:38:34AM +0300, drug via Digitalmars-d-learn wrote:
> 02.07.2017 09:52, H. S. Teoh via Digitalmars-d-learn пишет:
[...]
> > Take a look at the docs that describe the "%(...%)" nested format
> > specifiers. For example:
> >
> > int[] arr = [ 1, 2, 3 ];
> > writefln("%(%s | %)", arr);
> >
> > Output:
> >
> > 1 | 2 | 3
> >
> > Explanation: %(...%) means a nested format specifier, where the
> > stuff enclosed between %( and %) are applied to each array element
> > (actually, range element -- it works for arbitrary input ranges). In
> > this case, the stuff in between is "%s | ", which is treated as "%s"
> > followed by the delimiter " | ". So each array element is formatted
> > with %s, and " | " is inserted as a delimiter.
> >
> > A slightly more interesting example:
> >
> > int[] arr = [ 1, 2, 3 ];
> > writefln("%(<%s>%|, %)", arr);
> >
> > Output:
> >
> > <1>, <2>, <3>
> >
> > Explanation: the stuff between %( and %) is "<%s>%|, ", which is
> > understood as applying "<%s>" to each array element, and treating ",
> > " as the delimiter. The "%|" separates the per-element component
> > from the delimiter; this distinction is important because we want
> > the ">" to appear after every element including the last one, but we
> > don't want the ", " to appear after the last element.
> >
> > You can also nest %(...%) to handle multidimensional arrays. Here's
> > my favorite example:
> >
> > auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
> > writefln("%([ %(%s, %) ]%|\n%)", m);
> >
> > Output:
> >
> > [ 1, 2, 3 ]
> > [ 4, 5, 6 ]
> > [ 7, 8, 9 ]
> >
> > Hope this helps!
[...]
> Cool! Is it D only or could be used in printf (C/C++)?
AFAIK, this is a D-specific extension.
T
--
Why do conspiracy theories always come from the same people??
Re: std.json cannot read an array floats back from file
Yuri wrote:
Hi there,
consider the following simple use case:
import std.json;
float[] floats = [1,2,3];
JSONValue j = "{}".parseJSON;
j.object["floats"] = floats;
std.file.write("test.json", j.toString);
JSONValue jj = readText("test.json").parseJSON;
jj.object["floats"].array[1].floating.writeln;
It is expected to print '2' in the console, however an exception is
thrown:
std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235):
JSONValue is not a floating type
while the below works fine:
import std.json;
float[] floats = [1,2,3];
JSONValue j = "{}".parseJSON;
j.object["floats"] = floats;
j.object["floats"].array[1].floating.writeln;
any pointers to what could be going wrong?
'cause what you got back is `JSON_TYPE.INTEGER`. dunno why it is there at
all, as JSON has no "integers" per se, but it read as integer, and
`.floating` failed type checking.
so, write your own wrapper that will convert INTEGER/UINTEGER/FLOAT to
`double`. i think this is the best solution (if there can be "best
solution" with std.json at all).
Re: std.json cannot read an array floats back from file
On Sunday, 2 July 2017 at 21:07:40 UTC, Yuri wrote: It is expected to print '2' in the console, however an exception is thrown: std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235): JSONValue is not a floating type I think it just read the json string of "1" as being an integer instead of a float, so the reader thought it was integral instead of floating. It should prolly just transparently auto-convert, but it doesn't seem to. Try accessing the int instead and see waht happens.
std.json cannot read an array floats back from file
Hi there,
consider the following simple use case:
import std.json;
float[] floats = [1,2,3];
JSONValue j = "{}".parseJSON;
j.object["floats"] = floats;
std.file.write("test.json", j.toString);
JSONValue jj = readText("test.json").parseJSON;
jj.object["floats"].array[1].floating.writeln;
It is expected to print '2' in the console, however an exception
is thrown:
std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235):
JSONValue is not a floating type
while the below works fine:
import std.json;
float[] floats = [1,2,3];
JSONValue j = "{}".parseJSON;
j.object["floats"] = floats;
j.object["floats"].array[1].floating.writeln;
any pointers to what could be going wrong?
Re: D and .lib files. C++/Other?
Ahh, you need to initialise the D runtime before you call any functions that depend on it (e.g. ones that interact with the file system). declare extern "C" int rt_init(); in your c++ code and call it before ConsoleWrite and it should work. Honestly i did try this and it didnt correct the problem... HOWEVER... I had been deleting the dll page VS and Xamarin always generate with a shared dll project as since i got dlls working with D in the first place(I was slow to figure it out) it worked just fine without the dllmain page they generated... Placing that back in there now that weve come this far corrected the problem-> Without the need to even write rt_init in D or C++. Thank you both very much for the help and information you guys have provided this problem is finally solved! ___ IF anyone happens to come across this thread in the future and has the same problem i did -> Note: Probably involving the use of Xamarin/MonoDevelop or Visual Studio with dll creation or compatibility with C++ I'd be happy to create a couple of sample projects and list the stuff it required me to install for it all to work. I'm not going to do that at this moment as since I had to ask it seems i MAY be the only moron who seemed to have this issue? Anyway Bye everyone!
Re: strange static assert failure
On Sunday, 2 July 2017 at 08:55:42 UTC, Basile B. wrote: The second assert fails. Do you know why ? pass your way, i've forgot the typeof()... everything is okay actually.
Re: D and .lib files. C++/Other?
On 2017-07-01 21:11, Damien Gibson wrote: As well I only intended to use shared libraries not static ones... Well, you can use shared libraries in two different way, dynamic linking or dynamic loading. Dynamic linking is when you declare your external symbols as usual and you link with the shared library at build time. Dynamic loading is when you declared your external symbols as function pointer and you don't link with the shared libraries at build time. You then use "dlopen" and the family of functions on Posix and "LoadLibrary" on Windows to load the shared library at runtime. When using dynamic linking on Posix you link directly with the shared library. When using dynamic linking on Windows you don't link directly with the shared library but instead link with an import library, which is basically a static library (as far as I understand). I would assume that this import library has the same problem as any other static library. When using dynamic loading you don't have to worry about these different formats at all. You can read more about static linking vs dynamic linking vs dynamic loading and about the problems with the different formats in the dlang blog [1] and here [2]. [1] http://dlang.org/blog/2017/06/26/project-highlight-derelict/ [2] http://derelictorg.github.io/bindings/ -- /Jacob Carlborg
strange static assert failure
I played with some strange stuff that are allowed, i.e "super"
and "this" as BasicType, when I've reached this:
class B
{
super ringuard(){return null;}
void foo()
{
auto crate = ringuard();
pragma(msg, typeof(crate));
static assert(typeof(crate).stringof == Object.stringof);
static assert(is(crate == Object));
}
}
The second assert fails. Do you know why ?
Re: std.string.format call from varyargs
02.07.2017 09:52, H. S. Teoh via Digitalmars-d-learn пишет:
On Sun, Jul 02, 2017 at 12:49:30AM +, LeqxLeqx via Digitalmars-d-learn
wrote:
Hello!
How does one go about invoking a templated-variatic function such as
std.string.format with an array of objects?
For example:
string stringMyThing (string formatForMyThings, MyThing[] myThings)
{
return format(
formatForMyThings,
myThings
);
}
In executing the above, the 'format' method always interprets the
entire array 'myThings' as the first argument to the format, and no
arguments afterwards, resulting in 'orphaned' format specifiers if the
array is longer than a single element. Even if the array is only a
single element, the formatter will wrap the result of the element's
'toString()' method with '[' and ']'
I really don't want to write my own format parser.
Any help would be much appreciated!
[...]
Take a look at the docs that describe the "%(...%)" nested format
specifiers. For example:
int[] arr = [ 1, 2, 3 ];
writefln("%(%s | %)", arr);
Output:
1 | 2 | 3
Explanation: %(...%) means a nested format specifier, where the stuff
enclosed between %( and %) are applied to each array element (actually,
range element -- it works for arbitrary input ranges). In this case, the
stuff in between is "%s | ", which is treated as "%s" followed by the
delimiter " | ". So each array element is formatted with %s, and " | "
is inserted as a delimiter.
A slightly more interesting example:
int[] arr = [ 1, 2, 3 ];
writefln("%(<%s>%|, %)", arr);
Output:
<1>, <2>, <3>
Explanation: the stuff between %( and %) is "<%s>%|, ", which is
understood as applying "<%s>" to each array element, and treating ", "
as the delimiter. The "%|" separates the per-element component from the
delimiter; this distinction is important because we want the ">" to
appear after every element including the last one, but we don't want the
", " to appear after the last element.
You can also nest %(...%) to handle multidimensional arrays. Here's my
favorite example:
auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
writefln("%([ %(%s, %) ]%|\n%)", m);
Output:
[ 1, 2, 3 ]
[ 4, 5, 6 ]
[ 7, 8, 9 ]
Hope this helps!
T
Cool! Is it D only or could be used in printf (C/C++)?
Re: weird error message
02.07.2017 04:06, Ali Çehreli пишет: On 07/01/2017 04:56 PM, crimaniak wrote: > about very long error messages generated in some > cases. Please submit a bug report. The compiler may be able to abbreviate certain types. For example, in this case most of the error message text is values of a static array elements. Ali I had error messages 256K+ length in case of complex templates. That's was really annoying but I've managed)
Re: std.string.format call from varyargs
On Sun, Jul 02, 2017 at 12:49:30AM +, LeqxLeqx via Digitalmars-d-learn
wrote:
> Hello!
>
> How does one go about invoking a templated-variatic function such as
> std.string.format with an array of objects?
>
> For example:
>
> string stringMyThing (string formatForMyThings, MyThing[] myThings)
> {
> return format(
> formatForMyThings,
> myThings
> );
> }
>
>
>
> In executing the above, the 'format' method always interprets the
> entire array 'myThings' as the first argument to the format, and no
> arguments afterwards, resulting in 'orphaned' format specifiers if the
> array is longer than a single element. Even if the array is only a
> single element, the formatter will wrap the result of the element's
> 'toString()' method with '[' and ']'
>
> I really don't want to write my own format parser.
> Any help would be much appreciated!
[...]
Take a look at the docs that describe the "%(...%)" nested format
specifiers. For example:
int[] arr = [ 1, 2, 3 ];
writefln("%(%s | %)", arr);
Output:
1 | 2 | 3
Explanation: %(...%) means a nested format specifier, where the stuff
enclosed between %( and %) are applied to each array element (actually,
range element -- it works for arbitrary input ranges). In this case, the
stuff in between is "%s | ", which is treated as "%s" followed by the
delimiter " | ". So each array element is formatted with %s, and " | "
is inserted as a delimiter.
A slightly more interesting example:
int[] arr = [ 1, 2, 3 ];
writefln("%(<%s>%|, %)", arr);
Output:
<1>, <2>, <3>
Explanation: the stuff between %( and %) is "<%s>%|, ", which is
understood as applying "<%s>" to each array element, and treating ", "
as the delimiter. The "%|" separates the per-element component from the
delimiter; this distinction is important because we want the ">" to
appear after every element including the last one, but we don't want the
", " to appear after the last element.
You can also nest %(...%) to handle multidimensional arrays. Here's my
favorite example:
auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
writefln("%([ %(%s, %) ]%|\n%)", m);
Output:
[ 1, 2, 3 ]
[ 4, 5, 6 ]
[ 7, 8, 9 ]
Hope this helps!
T
--
Tech-savvy: euphemism for nerdy.
