Re: float has too much precision
On 2020-04-21 22:10, Steven Schveighoffer wrote:
On 4/21/20 3:47 PM, Faux Amis wrote:
I'm dumbfounded, why does the following code write '35' on DMD32 D
Compiler v2.091.0-dirty?
module magic;
float magic( float f )
{
return f + 35f - f;
}
void main()
{
import std.stdio;
writeln( magic(1_000_000_000f) );
}
On run.dlang.io, it prints 64. Also on my mac.
Possibly it's working because intermediate floating point calculations
are generally done at max precision. On your system, that might be
80-bit reals.
Also possible that some optimization is figuring out that it can just
return 35f?
Try instead:
float magic( float f)
{
float result = f + 35f;
return result - f;
}
Is it worth worrying about? floating point is supposed to be inexact and
subject to variance on different machines.
-Steve
No, it doesn't matter. I just wanted to understand why it happened.
It seems splitting it up did the trick. So intermediate it is.
Thanks!
float has too much precision
I'm dumbfounded, why does the following code write '35' on DMD32 D
Compiler v2.091.0-dirty?
module magic;
float magic( float f )
{
return f + 35f - f;
}
void main()
{
import std.stdio;
writeln( magic(1_000_000_000f) );
}
Re: Is there an opposite of .toString()?
On 2017-10-14 05:47, Jonathan M Davis wrote:
On Saturday, October 14, 2017 00:18:35 myst via Digitalmars-d-learn wrote:
I'm sorry if this has been answered already, it seems like a very
basic question.
There is .toString() method convention for printing, but I can
not find anything alike for reading. Is there something like
operator>>() in C++? What's an ideomatic way of reading an object?
The function to use for conversions in general is std.conv.to. And really,
there isn't much of a reason to ever call toString. Functions like writeln,
format, and to may use it internally, but it's more or less an anti-pattern
to do so in your own code - especially if we're talking about generic code.
If you're looking to convert something to string, to!string works with
pretty much everything and toString works with considerably less. And if
there's a generic way to convert from string to something else, it's also
with to - e.g. to!int("42"). However, for that conversion to work, it either
has to be a built-in type so that to understands it, or the type will need a
constructor that takes a string. In general, in order to generically convert
to a user-defined type, either that target type must have a constructor that
accepts that source type, or the source type must define opCast or an alias
to convert to the target type. std.conv.to is very powerful, but it does
need to have something to work with. If anything approaching a standard
conversion exists, it can be done with std.conv.to; otherwise, it's going to
depend on the type.
I think that in general, you're going to find that converting to a string
works with most everything, but aside from built-in types, converting from a
string with std.conv.to is unlikely to work. _Some_ types do have
constructors that take strings, but most don't. Built-in types will work,
because std.conv.to understands how to do that conversion. For user-defined
types, either you're likely going to have to parse the string yourself, or
they may contain another function for doing the conversion (for instance
std.datetime.systime.SysTime uses toISOExtString and fromISOExtString to
convert to and from the ISO extended format for a date and time and has
other functions for other time formats).
You can also check out std.conv.parse, which acts similarly to std.conv.to,
but whereas to converts the entire string, parse converts the first portion
of a string and therefore is meant to allow for parsing multiple values from
a string.
- Jonathan M Davis
Thanks for the proper/complete reply ;)
Re: html fetcher/parser
On 2017-08-13 19:51, Adam D. Ruppe wrote: On Sunday, 13 August 2017 at 15:54:45 UTC, Faux Amis wrote: Just curious, but is there a spec of sorts which defines which errors should be fixed and such? The HTML5 spec describes how you are supposed to parse various things, including the recovery paths for broken markup. My module, however, isn't so formal. I just used it for a web scraping thing at work that hit a few hundred sites and fixed bugs as they came up to give good enough results for me (one thing I found is a lot of sites claiming to be UTF-8 are actually latin-1, so it validates and falls back to handle that. My http thing, while buggier, is similar - I hit a server once that ignored the accept gzip header and always sent it anyway, so I had to handle that... and I noticed curl actually didn't!) So on the one hand, there's surely still bugs and weird cases, but on the other hand, it did get a fair chunk of real-world use so I am fairly confident it will be ok for most things. Sounds good! (Althought following the spec would be the first step to a D html layout engine :D )
Re: html fetcher/parser
On 2017-08-13 01:49, Soulsbane wrote: On Saturday, 12 August 2017 at 19:53:22 UTC, Faux Amis wrote: I would like to get into D again by making a small program which fetches a website every X-time and keeps track of all changes within specified dom elements. fetching: should I go for std curl, vibe.d or something else? parsing: I could only find these dub packages: htmld & libdominator. And they don't seem overly active, any recommendations? As I haven't been using D for some time I just don't want to get off with a bad start :) thx I've the requests module nice to work with: http://code.dlang.org/packages/requests Thanks, looks nice! I'll try it if Adam's modules fail me :)
Re: html fetcher/parser
On 2017-08-12 22:22, Adam D. Ruppe wrote:
On Saturday, 12 August 2017 at 19:53:22 UTC, Faux Amis wrote:
[...]
[...]
---
// compile: $ dmd thisfile.d ~/arsd/{dom,http2,characterencodings}
import std.stdio;
import arsd.dom;
void main() {
auto document = Document.fromUrl("https://dlang.org/";);
writeln(document.optionSelector("p").innerText);
}
---
Nice!
[...]
Document.fromUrl uses the http lib to fetch it, then automatically parse
the contents as a dom document. It will correct for common errors in
webpage markup, character sets, etc.
Just curious, but is there a spec of sorts which defines which errors
should be fixed and such?
[...]
Bonus fact:
http://dpldocs.info/experimental-docs/std.algorithm.comparison.levenshteinDistanceAndPath.1.html
that function from the standard library makes doing a diff display of
before and after pretty simple
Thanks for the pointer!
html fetcher/parser
I would like to get into D again by making a small program which fetches a website every X-time and keeps track of all changes within specified dom elements. fetching: should I go for std curl, vibe.d or something else? parsing: I could only find these dub packages: htmld & libdominator. And they don't seem overly active, any recommendations? As I haven't been using D for some time I just don't want to get off with a bad start :) thx
Re: Porting Java code to D that uses << and >>> operators
On 2017-05-02 18:55, TheGag96 wrote: On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote: From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". This is something I've never understood. Why doesn't DMD implement the behavior their own language reference specifies? It seems like a very nice guarantee to have... https://github.com/dlang/dmd/pull/4035
Re: Porting Java code to D that uses << and >>> operators
On 2017-05-02 09:42, Jacob Carlborg wrote: On 2017-05-02 01:27, Faux Amis wrote: To me, this [2] suggests otherwise ;) Or am I missing something? [2] https://dlang.org/spec/expression.html#order-of-evaluation From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". Yeah, I am blind. Do all the compilers have this problem?
Re: Porting Java code to D that uses << and >>> operators
Not sure if this is still the case. But this [1] suggests that D doesn't have an evaluation order defined but Java does. [1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder To me, this [2] suggests otherwise ;) Or am I missing something? [2] https://dlang.org/spec/expression.html#order-of-evaluation
Re: Memory Allocation
On 2017-03-29 23:30, Faux Amis wrote: On 2017-03-29 21:19, Enigma wrote: I have a memory buffer allocated using different methods. It is simply a pointer and a size. Can you maybe just tread it like an array and slice it for allocation? *treat*
Re: Memory Allocation
On 2017-03-29 21:19, Enigma wrote: I have a memory buffer allocated using different methods. It is simply a pointer and a size. Can you maybe just tread it like an array and slice it for allocation?
Flat file CMS in D?
I was wondering, what would be the D equivalent of a flat file (as opposed to database driven) content management system?
Re: Implicit Interface Deduction
On Mon 14/12/2015 02:45, Chris Wright wrote:
On Sun, 13 Dec 2015 23:09:47 +0100, Faux Amis wrote:
interface IA {}
interface IB {}
interface IC {}
interface IAB : IA, IB {} interface IBC : IB, IC {}
class C : IA, IB, IC {}
// Defining C as : IAB, IBC // is not really scalable ;)
void main()
{
IAB c = new C(); // This doesn't work.
}
// Any suggestions?
If you really can't modify the declaration to suit, there are two options.
The first is to use casts. If a function would require something that's
both IA and IB, it takes an IA and casts to IB. It can use contracts to
ensure that things are of the right type. Ugly, but it works.
The second is to use templates to generate the interface you need and
appropriate wrapper classes. Then you need to manually wrap variables in
those generated wrapper classes wherever you need to pass them. You'll
end up with an API like:
alias IABC = Union!(IA, IB, IC);
void foo(IABC.Interface iabc) {}
auto c = new C;
foo(IABC.wrap(c));
If you really want to go this way, std.typecons might help. Or I hacked
up something horrific here: http://dpaste.dzfl.pl/0464f723580f
The thing is, I would like to define my class by its basic components.
It makes it very clear what type of functionality it exposes.
I do not see how the Union template is different from
interface IABC : IA, IB, IC
Maybe I don't get :(
Re: Implicit Interface Deduction
On Mon 14/12/2015 00:27, Ali Çehreli wrote:
On 12/13/2015 02:09 PM, Faux Amis wrote:
interface IA {}
interface IB {}
interface IC {}
interface IAB : IA, IB {}
interface IBC : IB, IC {}
class C : IA, IB, IC {}
// Defining C as : IAB, IBC
// is not really scalable ;)
It is not automatic at least because of implementation details: The
compiler should not generate a vtbl for every possible interface.
Is it acceptable to add IAB and IBC to C? If so, this works:
import std.stdio;
class C : IA, IB, IC, IAB, IBC {
void a() { writeln(__FUNCTION__); }
void b() { writeln(__FUNCTION__); }
void c() { writeln(__FUNCTION__); }
}
Ali
So, you would just add the combined interfaces to the definition.
Maybe with some nice separation this would be acceptable.
class C : IA, IB, IC,
IAB, IBC // implicit
{
// body
}
Enforcement would be difficult.
Forgetting IB, for instance, will still compile.
Implicit Interface Deduction
interface IA {}
interface IB {}
interface IC {}
interface IAB : IA, IB {}
interface IBC : IB, IC {}
class C : IA, IB, IC {}
// Defining C as : IAB, IBC
// is not really scalable ;)
void main()
{
IAB c = new C(); // This doesn't work.
}
// Any suggestions?
