I have a component that includes np.sqrt(1-x). This works fine for normal operation, since all inputs will strictly be between 0 and 1. However, when checking partials and providing an input array that goes all the way up to 1, the finite differencer will step past 1, and break the component. The inputs shouldn't be less than 0 either, so simply switching the direction of the finite difference wouldn't work.
The workaround is just using np.linspace(0, 0.99, 400) instead of np.linspace(0, 1, 400).
Is it possible to set allowable bounds for the finite differencing?
As of V3.1 there isn't a way to set bounds like that. Just make sure that you test the derivatives around a more well posed point, like around 0.5.
If you're having trouble getting things to work in the optimization context, since you might bump into both bounds ... well, thats why analytic derivatives are better :)
I need to know where I can change the range of the spell - THAIL SMASH 71077
the only thing i can see in the C++ code regarding this spell is this:
events.ScheduleEvent(EVENT_TAIL_SMASH, 20000, EVENT_GROUP_LAND_PHASE);
From:
https://github.com/azerothcore/azerothcore-wotlk/blob/master/src/server/scripts/Northrend/IcecrownCitadel/boss_sindragosa.cpp#L331
The main problem is that this spell have a main effect that is activated at 45 and 2 secondary effect that are activaded at 20 yard , but in game the secondary effects of the spell are actived at more than 20 yard, how i can resolve this ?
https://www.wowhead.com/spell=71077/tail-smash
I don't know if you remember but, when you extracted maps, mmaps and vmaps, you also extracted some files called "DBC".
These files are extracted from the client as well as the rest of the map files.
This means that every spell is "hard coded" into these files. Their effects, visuals and whatnot are not viable to modify because if you did and you lost these files, you would lose a lot of progress. If you extract new DBCs you would obviously not have these files. And so wouldn't other contributors.
So to fix this, there's a C++ file called SpellMgr.cpp in which people have been modifying spell attributes.
On this specific file, you have the spell you are looking for:
https://github.com/azerothcore/azerothcore-wotlk/blob/master/src/server/game/Spells/SpellMgr.cpp#L5624
They are already correcting the available targets for this spell with
spellInfo->EffectImplicitTargetA[0] = TARGET_DEST_CASTER_BACK;
So to get your expected results you would need to change the Radius of effect with a line like this one:
spellInfo->EffectRadiusIndex[1] = 20; // Spell effect 1 radius to 20y
spellInfo->EffectRadiusIndex[2] = 20; // Spell effect 2 radius to 20y
My Visual Studio keeps displaying the following warning (I think it's actually the Web Essentials plugin that produces it) but I'm not really clear why this is a problem? Can some explain please?
PS, Yes I understand what specificity is and how to calculate it, I just don't know why a specificity of 0,2,0 is a problem?
The above isn't the error message, it's standard hovering info when you move your mouse over a selector with WE. However, the problem you're facing is probably the same selector being specified twice in the same file.
Pekka's answer is practically correct, and probably the best way to think about the issue.
The starting point is 4 figures:
style id class element
0, 0, 0, 0
So in your case you have used 2 class names so its showing as 2 in the middle.
I didn't know before about artistic or artwork QR codes, while checking some of these codes, they are completely different from the regular standard QR code, but how is it possible to create this kind of QR code without loosing it's value (the scan result is the same) ?
These QR Codes are the most ones that amazed me:
http://www.hongkiat.com/blog/qr-code-artworks/
The only thing in common is the 3 corners, and they're different in style.
So my question is, what are the elements that we should preserve while creating such QR Codes ?
The most important things are:
Dark-on-light
Very nearly square modules
Modest light border
Substantially preserve the three-finder patterns
... and the first line of modules around them, which carries format info
... and the bottom-right alignment pattern, is helpful
The rest, the interior, can be substantially obscured and still be readable, certainly with high error correction. But messing with the elements above will tend to make it unreadable much more rapidly
I've seen this notation used a lot, and I was wondering, is there is any notable difference between these two notations?
element#id
{
property: 0;
}
and
element#id
{
property: 0px;
}
I use property: 0px; all the time, as I find it cleaner looking, but I'm not really sure if the browser interprets 0px differently than 0.
Does anyone know which one is better or correct?
Unit identifiers are optional, but there is no noted performance increase (although you are saving two characters).
CSS2 - From W3C CSS 2.1 Specification for Syntax and basic data types:
The format of a length value (denoted by <length> in this specification) is a <number> (with or without a decimal point) immediately followed by a unit identifier (e.g., px, em, etc.). After a zero length, the unit identifier is optional.
(Emphasis mine)
CSS3 - From W3C CSS Values and Units Module Level 3 (Currently in Candidate Recommendation at the time of this writing)
For zero lengths the unit identifier is optional (i.e. can be syntactically represented as the 0).
While the unit is optional when the value is 0, I tend to leave it in, as I can then tweak the values with Chrome's Developer Tools by clicking on the value and pressing the up/down arrow keys. Without a unit, that isn't really possible.
Also, CSS minifiers strip the units off of 0 values anyways, so it won't really matter in the end.
They are the same. The browser interprets both as 0, so go with whatever is more readable for you.
Zero of anything is zero. 0px = 0% = 0em = 0pt = 0
Most people leave the unit off because it is simply unnecessary clutter.
As far as I'm aware there is no difference between them, since 0px = 0em = 0ex = 0% = 0. It's purely up to you, as the developer, to decide what you like best (unless you have corporate coding standards that you need to follow, of course).
From most of the code samples I've seen, most people use the unitless version. To me, it just looks cleaner. If you're pushing a significant amount of data (say, if you're Google), those two bytes can add up to a lot of bandwidth, especially since you're quite likely to repeat them multiple times in your stylesheet.
Zero pixels is equal to zero inches and zero meters and so forth. 0 is all you need.
I personally find 0 cleaner than 0px. That's two extra characters that can add up. Why add extra bytes when you don't need to. I have see padding: 0px 0px 0px 0px which can easily be expressed as padding: 0 way too often.
You can use either - my best advice is not to worry too much but be consistent in doing it either one way or the other. I personally prefer to specify '0px' for the following reasons:
Using 0px makes things more consistent with all of the other 'px' sizes you've specified
It's also more verbose and makes it very clear that you're setting a zero length rather than a 'switch this off' flag
It's slightly easier to tweak a '0px' value to make it another value if required
zero-units Zero values don't need units. An easy way to save bytes in CSS is not include units when a value is 0. For instance, 0px and 0 are the exact same ...
http://csslint.net/index.html
If somebody gives you 0 EUR. It is that same like 0 Dollar or 0 Zloty etc. What you got is nothing = 0. That is why in the case of 0 you dont need to set a unit.
As the others say, it doesn't really matter if its 0, though I choose to add the measurements to all of my values so anyone else looking at my CSS files can gauge what measurements they're likely to deal with elsewhere.
I know that there should be no difference between 0px and 0 but I've found that sometimes there is.
I was trying to center an object like this:
position: absolute;
left: max(0px, calc((100vw - 400px)/2));
max-width: 400px;
It works but if you substitute 0px with 0 it doesn't.