|
While PI = math.asin(1) * 2 may be mathematically correct, it's probably not the most accurate representation of π you could create. It depends upon the arcsine function implementation. You might get lucky in case they shortcut the value for an argument of 1, and simply return the library's value of π. If not, they're going to do the arcsine calculation using a numerical method that will approximate something close to π.
In other words, it would be more precise if the library simply gave you its value of π. For casual calculations, the difference may not matter. If you're doing a simulation, having your value of π off by a couple bits could have long-term consequences.
Software Zen: delete this;
|
|
|
|
|
Interesting, that asin ine use of a math function.
|
|
|
|
|
|
And i understand only the 'inherit master page,inherit master page,inherit master page' part....
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
The topic actually contained two full stops. After reading the first few lines I had already expected it to contain none at all. However they didn't really help.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Rohan Leuva wrote: When you don't know what you're doing it's best to do it quickly"- SoMad>
Similarly, I think it was the Flying Karamazov Brothers who said, "It doesn't matter how you get there if you don't know where you're going."
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
Ah, that was so much easier than trying to figure out a captcha.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
It's on a website my kid sister probably doesn't frequent.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Was it like this?
Uncheck □ this -> □ if □ you □ are □ not □ a bot □.
|
|
|
|
|
No, just the one checkbox.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Can't find it with Google. Is the most relevant result hidden from me?
|
|
|
|
|
Wow, that's very ... uhm ... secure.
I once came across a site where they showed a series of pictures with checkboxes and you had to check all the vehicles and leave the rest unchecked. Try writing a bot for that.
|
|
|
|
|
Algorithm: Randomly check or uncheck each box. If there's five pictures, then you'll successfully bypass the security 1/32 times.
Bots have infinite patience, and checkbox-based security can usually be brute-forced.
|
|
|
|
|
jesarg wrote: 1/32 times
Are you assuming exactly one vehicle? I assumed that any, all, or none would meet the criteria.
Whoops, no, I see it now, sorry.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
There were about 30 pictures perhaps. If you only allowed a few tries before it locked up, it would be pretty secure, I suppose. (I'm not an expert) But nothing is 100% secure of course.
|
|
|
|
|
I thought this forum consisted of only experts! (then I ask myself why would I be here then!)
|
|
|
|
|
If you display a lot of pictures at once, then the system becomes just as annoying to users as a captcha.
Also, you'd have to maintain a large and constantly-changing database of pictures to keep the bot from memorizing which pictures are the vehicles.
In any case, defeating the bots is a much bigger task than people realize. If bot writers are willing to create advanced algorithms capable of deciphering a captcha, then they are willing to go to great lengths to defeat other security features, too.
|
|
|
|
|
I've seen that with "Kittens" and "Puppies" as well - very damn annoying!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
For something I'm working on, I want to test a given XmlElement with a provided XPath predicate to determine whether or not it's the droid node I'm looking for.
public static bool
IsMatch
(
this System.Xml.XmlElement Element
,
string Predicate
)
{
return ( Element.SelectSingleNode ( "self::node()[" + Predicate + "]" ) != null ) ;
}
I wasted an hour trying to get .[predicate] to work.
System.Xml.XmlDocument doc = new System.Xml.XmlDocument() ;
doc.LoadXml ( "<Foo Bar='Baz' />" ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "." ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::node()[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::*[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( ".[@Bar='Baz']" ).OuterXml ) ;
<Foo Bar="Baz" />
<Foo Bar="Baz" />
<Foo Bar="Baz" />
System.Xml.XPath.XPathException: '.[@Bar='Baz']' has an invalid token.
The book I have says . is equivalent to self::node() , but that's not true,
. returns a node, whereas self::node() returns a node-set, and you can only apply a predicate to a node-set.
Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
How about this?
public static bool IsMatch(this System.Xml.XmlElement element, string predicate)
{
return element.CreateNavigator().Matches("*[" + predicate + "]");
}
If you're going to be re-using the same predicate for a lot of elements, you might want to pre-compile it[^]:
public static bool IsMatch(this System.Xml.XmlElement element, XPathExpression compiledPredicate)
{
return element.CreateNavigator().Matches(compiledPredicate);
}
...
var compiledPredicate = XPathExpression.Compile("*[" + predicate + "]");
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, I'll try that too and maybe do some performance comparisons. Performance really isn't an issue with my current usage -- about forty elements being checked with a predicate provided on the command-line.
Your second implementation might make for the basis of an enumerator.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Found an interesting feature in Microsoft Dynamics Ax 2012 R2:
static void Job40(Args _args)
{
smmBusRelTable bus;
int i;
select count(RecId) from bus where
bus.BusRelAccount == bus.TopLevelAccount
;
info(strFmt("From count: %1", bus.RecId));
i = 0;
while select bus where
bus.BusRelAccount == bus.TopLevelAccount
{
i++;
}
info(strFmt("bus.BusRelAccount == bus.TopLevelAccount: %1", i));
i = 0;
while select bus where
bus.TopLevelAccount == bus.BusRelAccount
{
i++;
}
info(strFmt("bus.TopLevelAccount == bus.BusRelAccount: %1", i));
}
Running the job results in this output:
From count: 31597
bus.BusRelAccount == bus.TopLevelAccount: 1
bus.TopLevelAccount == bus.BusRelAccount: 31597
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
A badly designed operator override? At least fun to see that (bus.BusRelAccount == bus.TopLevelAccount) != (bus.TopLevelAccount == bus.BusRelAccount)
|
|
|
|