|
Thanks, "Round half down" was the term I was looking for. 
Almost, but not quite, entirely unlike... me...
|
|
|
|
|
how I would go about explaining what it's doing to the users. If you owe us money, we get more; if we owe you money, you get less.
“I have diligently numbered the days of pure and genuine happiness which have fallen to my lot: They amount to 14.” Abd-Ar Rahman III, Caliph of Cordoba, circa 950CE.
|
|
|
|
|
This is standard rounding
The irony is that people are so used to bankers rounding they get confused when they see ordinary rounding, but this is the kind you probably learned about in school!
Disregard, I'm an idiot
modified 8-Sep-14 1:41am.
|
|
|
|
|
JMK-NI wrote: This is standard rounding
No it isn't.
There is a huge difference between standard rounding and significant rounding.
There are also many different types of rounding scheme depending on the application: http://en.wikipedia.org/wiki/Rounding[^]
|
|
|
|
|
Well knock me down!
It's 6:30AM, I haven't had coffee yet!
|
|
|
|
|
Well it's now 6:43am, my first meeting with my supervisory team was an hour ago and I have already spoken with my boss onshore, so the day is well underway.
Only another 14 or 15 hours still to go. 
Feeling  already.
|
|
|
|
|
JMK-NI wrote: Disregard, I'm an idiot
Well, JMK-NI, don't worry too much: you are in the place for idiocy. It's kind of like a "contagious skin rash," here, on the Lounge, it breaks out in different people, and makes different people scratch in different places, while others scratch their heads.
cheers, Bill
“I have diligently numbered the days of pure and genuine happiness which have fallen to my lot: They amount to 14.” Abd-Ar Rahman III, Caliph of Cordoba, circa 950CE.
|
|
|
|
|
|
My understanding of rounding to N significant figure is like this:
1234 to 3 significant figures = 1230
1235 to 3 significant figures = 1240
1236 to 3 significant figures = 1240
The trouble is, I need
1234 to 3 significant figures = 1230
1235 to 3 significant figures = 1230
1236 to 3 significant figures = 1240
The point is, rather than rounding up or down depending on whether the N+1th digit is 4 or 5, but whether it is 5 or 6.
Almost, but not quite, entirely unlike... me...
|
|
|
|
|
How about "N Significant Half-Down Rounding[^]"?
Whether I think I can, or think I can't, I am always bloody right!
|
|
|
|
|
Round half down + Significant.
|
|
|
|
|
Cheers.
I think "round half down" is the term I needed.
Almost, but not quite, entirely unlike... me...
|
|
|
|
|
So depending on how you want to treat negative numbers you want either "Significant digits round half down" or "Significant digits round half towards zero".
|
|
|
|
|
All values are positive, due to the nature of the application.
"Round half down" was the term I was looking for.
Thanks for your help. 
Almost, but not quite, entirely unlike... me...
|
|
|
|
|
The 1.5 -> 1 is a little strange. Except for that you can use
double MagicFormula(double x)
{
var d = Math.Log10(x);
var f = Math.Pow(10.0, d);
var res = Math.Round(x / f, 0) * f;
var res2 = Math.Round(res, 0);
return res2;
}
Michael Pauli
|
|
|
|
|
|
There's going to be a beer discussion on HTML5 tomorrow at the Intel conference and I want your thoughts on the following
1. Is HTML5 the right choice for building an app? Obviously if it's a web app, then yes, but is it the right choice if you're writing, say, Windows 8 apps?
2. Are there any misconceptions about HTML5? To me: not from where I stand, but I wonder if this is universal. HTML5 isn't a language, it's markup, and it's the Javascript and CSS3 that give it its power. It's slow - though not as slow as yesterday - and it's casual with types, which can make it a nightmare to debug. These are all known quantities though.
3. What's the main issue with using HTML5 to create apps? Apart from speed? And type safety? And the fact it's a functional language when many devs thing in OOP terms? And the fact that things never work perfectly between browsers and the HTML5 "standard" is often merely a serving suggestion?
4. Does HTML5 actually have a future beyond the browser? Will it all go away and we'll be writing our apps in Go or Swift on all platforms? Does HTML5 even have a future on the webbrowser?
cheers
Chris Maunder
|
|
|
|
|
1. Probably not today, but soon.
2. I don't think I have any either - but then again, if I do, I wouldn't think they were misconceptions! The main thing I hear time and again is "slow" - form people who jsut assume it must be slow and haven't tried it. I tend to find it's not too slow at the client side (certainly faster than some of the XAML stuff I've used) if it's well written, but the background delay fetching data makes it seem much slower at times, because folk compare it to a more local solution.
3. Speed is still an issue - but becoming less so. Typescript helps with type safety and OOPism to some extent. Things working perfectly across platforms? It's a lot better than it was.
4. I don't think it will go away to be replaced by anything for a LONG time - because all browses would have to adopt whatever the new thing is - can you see IE supporting Swift?!
My question would be, will Javascript be allowed to mature to the point it is a 'real' language.
Or will another language come along to replace it?
There seems to be no reason I can see for someone not to write a new language that has all of the goodness of a real, strongly typed, OO language, while being scriptable and having native DOM access.
So the problem then becomes one of browser introduction - nobody will use it on a web site unless most browsers support it - no web browser will support it if there's nothing in it for them..
Typescript or something like it is probably the best solution - effectively have a front-end compiler for a language that spits out javascript rather than bytecode.
PooperPig - Coming Soon
|
|
|
|
|
Chris Maunder wrote: beer discussion
I will share my thoughts if you share the beer! 
1. Yes. IMHO HTML5 (all the package I mean) is the right for front end. There is no reason and there is no need for native, but a standard based UI, that can be fitted to any device.
2. As HTML5 is used like a selling-sticker on every development related product today, it is hard not to spread misconceptions...(A component package is HTML5 because it uses AJAX calls from client to bind to data!) I think that the most important thing is to separate the markup HTML5 from the 'package' HTML5, otherwise we will have a new generation of developers who will not be able to move on if new ways will be discovered...
3. The HTML-JavaScript-CSS trio is well up for application development. It's true that you have to understand tour environment in depth. But hey! That's all the fun. Take some 'pile of metal junk' and bind it to your will...OOP is a great thing but not sure have part in UI (and HTML is for UI), no problem to use OOP in JavaScript so I can't see too much problems to use it - except to avoid the nasty parts of it...It's true that the standard is like the white lines on our rode - a mere suggestion, but that true also for native development. every OS and every device has it's way and you have to adopt to them...
4. I do not think HTML should expend out-of-browser. For that there are tools much better suited for the task. However in the current environment (in browser) there is no better that the HTML thing today. The future of HTML is unpredictable, by nature human beings (and developers ARE human beings, after all) is not to stand still, so in the near of far future someone will think of a new way to do old things and maybe HTML will not have place in it...But for the near future (up to 10 years I would say) a well designed HTML application can be a very good solution...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
1. Yes for web, hell no for Windows 8. Nobody in their right mind would choose Javascript over C#, or HTML/CSS/Javascript over the whole Native C#/XAML/MVVM option offered natively on Windows 8 given the option.
2. I think you have covered the main points
3. I guess that you will probably need a framework, or really multiple, to get the most out of it, and so the size of all of the libraries needed + your own css and javascript could be close to 1MB when you're done. Doesn't seem like much, but for somebody visiting your site on a mobile device over a 3g connection it is, and they will probably leave before your site loads, or even worse hit cancel and end up with a wonky version. The other issue is that css animations are still horrid on mobile browsers, even something completely standard such as Twitter Bootstrap's accordion renders horribly on any mobile devices I've tested.
4. I don't think it has a future beyond the browser, I think it will be around for a while inside the browser though
|
|
|
|
|
imho to discuss HTML, or any other mark-up standard (the theoretical standard as defined you know where, and the actual usage as embodied you know where), as suitable for an "application" is a basic semantic snafu that can only lead to confusion.
My own view of the whole circus of contemporary "web reality" (servers, clients, HTML, CSS, JavaScript, jQuery, etc.) is that it is much like the "Middle East:" like the patchwork quilt of countries created by the "great powers" at the end of WWI at Versailles ignoring geographic, ethnic, religious, and tribal boundaries. To a large extent a "least common denominator" compromise outcome of competing market realities of a few large companies.
But, if you are forced to engage in this type of chimeric debate, then I would see HTML as defining the "skin" of the structure (the DOM ?) for what you might analogize to the "view" in the model-view-controller paradigm; a rather lame view-engine that had to have a heart-transplant (CSS) to cope with web-sites/pages demanding more and more functionality.
And, ECMAScript ? Well, certainly mis-named JavaScript since it had zilch to do with Java. Also a critter, like HTML, that has been somewhat transformed by the addition of surgical prostheses: i.e., jQuery.
It wasn't until I stumbled across Petr Stanicek's Color Scheme Designer site: [^]several years ago ... now re-incarnate as Paletton.com: [^] ... that I felt I had really seen a true "application" done entirely with HTML and JavaScript. An application informed by a vast knowledge of the physics of light/color, and the nature of human visual perception, and physiology.
But, CSD aka Paletton, is an application lending itself to very slow, deliberate, interactions with a finite set of outcomes/consequences/color-choices.
While I am sure that beer and human fellowship will be plentiful at this soiree of literati, I fear that: unless "application" is really defined in very specific terms, cognitive exchanges may be as transient as the beer
Seems like an interesting question to ask would be: what would be an alternative ... given no constraints by current web "reality" ... to HMTL+CSS ?
And, what happens if, and when, everything goes "into the cloud" ?
cheers, Bill
“I have diligently numbered the days of pure and genuine happiness which have fallen to my lot: They amount to 14.” Abd-Ar Rahman III, Caliph of Cordoba, circa 950CE.
|
|
|
|
|
Consider that using HTML of any variant means you are using a technology designed for displaying a document, and using it to model software interfaces, when there are technologies out the for that purpose.
Consider that all JavaScript is non-deterministic. (It is also a low level language running around trying to pretend it isn't - chew on that)
I will not try to argue about practicalities though, for most things Web Dev is probably the right choice.
It is my opinion that if MS would come off it and let folks host their own corporate/internal/etc app store that say you have access to via domain joining or something... then maybe you could make an argument to build all your stuff in XAML/native, because at that point the whole deployment/updating thing is on par with web apps.
|
|
|
|
|
In my opinion, aside from the obvious Web APP, HTML5 is far from the best for writing applications, and it will never be if we don't have huge breaking changes. In fact, I think that the Microsoft decision to abandon Silverlight was extremely stupid. Yeah, HTML5+JavaScript can do the same. Yet, Java can do the same that .NET does (even if it is more verbose) and .NET definitely have its place. So, I believe many arguments about Silverlight and HTML5 will be pretty similar.
HTML5 (with CSS3 and JavaScript support) can do a lot, yet I can't say I know worse kind of legacy than the one present in HTML. Even if C is very old, I think the most bizarre things I saw in my life are found in the HTML + JavaScript combination. So, to me (and to many developers I know) HTML5 only added new features to a nightmare of maintainability, which is not going away by the new functionalities.
|
|
|
|
|
Chris Maunder wrote: Does HTML5 even have a future on the webbrowser?
HTML-NN (where NN is an integer) will have a future on your browser.
HTML2 is still in use all over the place
|
|
|
|
|
I think it really depends on the platform you're writing for. If you're writing desktop stuff (yeah, I know, the desktop is dead, yadda yadda) like I do you may not even care about HTML much. OTOH if it's extensions are fast enough and you're writing web stuff, yeah. I've been studying it myself and don't really buy that native machine apps (Win8) have to be written in a markup language in the first place. It's one way of doing things, I guess, but I don't think it's the broad brush that everyone wants it to be.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
