|
So have a nice Weekend 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I second this. I learn a lot in these discussions. 
|
|
|
|
|
I can think that Zero does not offer much trade use?
You either trade or not.
If i give you 10 for somthing of 5 value, you give me 5 back.
but if i give you 10 for something of 10 value, you don't give me anything back.
Nothing/Zero is similar.
- yes its zero, but for the purpose of the trade, nothing.
contrast with mathematics, 2x0 - not sure what trade situation except the trader turns up with nothing to trade. I'm not going to work out some maths to know he aint got anything to trade.
|
|
|
|
|
11 is far from logical. Afterall, using an 11-based system would exclude roughly half of the population from counting.
|
|
|
|
|
It's hard to see the past with future knowledge.
There were 2 concepts. COUNTING, which everyone had to learn how to do.
And NOBODY bothered COUNTING ZERO of something. Does a cow farmer record ZERO Sheep, ZERO Goats, etc... Nope, he counts cows... And if the count is ZERO... I am certain he is in PANIC mode. LOL
The other concept was MATH. And that is where ZERO is a strict requirement.
And we learn numbers first, then math to this day, but we learn more math sooner.
Also, I have a daughter, I remember teaching her to count. I can't remember teaching her to start at ZERO.
==
Here is something interesting about the NAMES for our numbers. Which are NOT good names in English. Because we USED to use BASE 12. The repetition parallel naming starts at 21 (21, 31, 41).
But not 11 (which should be tenny-one, or ten-1 or One-teen [best]... Indicating 10 Plus one)
But because we used to be base 12 (12 inches in a foot, 12 in dozen, etc)... the TEENS start at 13.
Also, implied... Many people were counting much passed this.
And mathematically speaking... Base 12 was superior. It divides by 2,3 and 4. Something 10 cannot do without decimals.
And don't get me started with decimals. try that in ROMAN Numerals. In fact, division of Roman Numerals (without converting to decimal in your head), takes YEARS to master.
So, now we realize we have COUNTING, MATH, and REPRESENTATION...
The last one becomes important. How many times have you seen someone open and close their hands to tell you a bigger number like 20, or 30... Do that using Hexadecimal Representation. LOL...
|
|
|
|
|
Impressive, thanks for this 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Got an ASP.NET MVC Core app with a SQL Server database.
I have a decimal field in the database, gets correctly converted to decimal in .NET, and then it gets send to the front-end as-is (1.2).
The input (type="number") shows 1,2 (one comma two), but when I send it to the back-end it's converted to 12.
Even 1.2 (one dot two) is saved as 12.
Even when I do absolutely nothing my number is converted to 12.
I'm sure there's a good explanation, like Vue.js messing up my numeric fields or whatever.
Googling the problem gives me all kinds of libraries for working with numbers.
I'm so happy that after about 30 years of web development we can finally handle numbers without hassle 
Guess I'll just be happy I'm not working with dates.
Or worse, CSS.
|
|
|
|
|
Your database sounds like it is storing everything in an English Culture. The UI sounds like it uses the Dutch culture.
Do you convert your value to the correct culture before saving?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
As a decimal, culture should be irrelevant, and I can't see Sander storing numbers as strings in his DB - that's a rookie mistake.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It's a decimal going out the db. It's not when it is displayed, or when it is sent back to the database.
Sander Rossel wrote: The input (type="number") shows 1,2 (one comma two), but when I send it to the back-end it's converted to 12.
Even 1.2 (one dot two) is saved as 12.
"Number" might be referring to "ints", not decimals at all.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: "Number" might be referring to "ints", not decimals at all.
Because HTML input only knows "number" and not "decimal" 
Maybe I should just use an input type="text" and work with a mask.
HTML is as useful as a pair of scissors while running down the stairs.
I'm not even sure which I hate more anymore[^], HTML or CSS.
|
|
|
|
|
Sander Rossel wrote:
HTML is as useful as a pair of scissors while running down the stairs.
Wooden stairs, on your socks. With JavaScript-rockets for a small boost.
Since it is a string, again the original question? What culture, and where is it turned back into a real decimal? Or is that "secretly/magically" done by the framwork, a la VB?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The browser posts a double as "1.2" in JSON (independent of culture I hope) and .NET Core does the deserialization (hopefully also independent of culture).
Even after changing my separator in Windows from comma to dot the deserialization only works with comma.
I'm just baffled that "1.2" is deserialized as 12 and only "1,2" is deserialized as 1.2 
|
|
|
|
|
Sander Rossel wrote: The browser posts a double as "1.2" in JSON (independent of culture I hope) and .NET Core does the deserialization (hopefully also independent of culture).
You mean it should magically assume the correct one? *
Sander Rossel wrote: Even after changing my separator in Windows from comma to dot the deserialization only works with comma.
I'm just baffled that "1.2" is deserialized as 12 and only "1,2" is deserialized as 1.2
Baffle yourself some more and set it to some non-default character like a question mark. Doing so may break several applications at once, but is usefell during testing.
*) JSON is a string, and has a culture in which the number is expressed/encoded within that string. So it is not a double there. When deserializing, it has to know which culture the client is using.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
FOUND IT!!!
Apparently, I wasn't posting JSON at all...
The entire thing got posted as form data and that uses different deserialization rules for obvious(???) reasons 
Changed the type of AJAX to JSON and 1.22 is now serialized as 1.22 (but 1,22 is completely invalid ).
|
|
|
|
|
Deserialized into a decimal again? So an implicit conversion again, hidden?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yep, now I can't get it to break with an input type="number" (unless I leave it completely empty, but I can validate for that)
|
|
|
|
|
1.22E+0?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I store it in two date fields.
I convert the dates to milliseconds and combine them and with string concatenation place a dot or decimal between them (dependent on culture) 
The culture is stored as an array of bits 
|
|
|
|
|
What! And miss out on the advantages of storing it in a UNIQUEIDENTIFIER column? Think of the math you could do with 128 bit unsigned fields!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Culture's probably not the problem (if it is it's between browser and back-end, not DB and back-end).
It's posted as string "1.2" (no matter if the separator in the input is actually a comma or dot) and .NET converts that to a whole number.
It's probably a string because it's bound (with Vue.js) to an input and inputs are always strings.
Anyway, you'd think that converting "1.2" to 1.2 before posting would solve the problem.
Unfortunately, it doesn't...
And here I was thinking saving some data was going to be easy
|
|
|
|
|
If it was easy, everybody would do it. You see what happened when we had VB6 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I had a course on a no-code platform last week (Betty Blocks).
The more I code, the more I like no-code
|
|
|
|
|
Sander Rossel wrote: I had a course on a no-code platform last week (Betty Blocks).
The more I code, the more I like no-code
Having worked with and on multiple code-generators, I'm a bit sceptical, but looks promising overall. And free to try by the looks of it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Quote: I'm so happy that after about 30 years of web development
I always thought you are very much younger, please correct your Profile picture 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
