|
tef posted:in excel ???? its this
|
#
?
Oct 25, 2023 03:56
|
|
|
|
| # ? May 26, 2024 16:46 |
|
|
langs shouldn't have built in number types at all. if you need to do math, you should use a library that implements the type of math you need to do
|
|
#
?
Oct 25, 2023 07:57
|
|
|
Sapozhnik posted:actually that's an interesting question, how does big-boy financial software do math anyway? (very carefully) they do whatever the number type in the sql database does op
|
|
#
?
Oct 25, 2023 07:58
|
|
|
Captain Foo posted:would have expected a folding chair with 1998 Foley and Van Dam telnet star wars, but it's mankind vs. the undertaker
|
|
#
?
Oct 25, 2023 08:32
|
|
|
Sapozhnik posted:actually that's an interesting question, how does big-boy financial software do math anyway? (very carefully) integers with a system-wide scale ime. the kind of stuff where rounding outcomes tend to be bespoke (i at first wrote "firmly specified" but had some bad reverse engineering flashbacks).
|
|
#
?
Oct 25, 2023 10:11
|
|
|
My first big boy job was working on an 'enterprise resource planning' app built with Delphi 5 and (I have to google this lol) InterBase, all monetary amounts were doubles, rounding was implemented by the stdlib stringification, truncation, and parsing back to double. To my knowledge that place continues to be a profitable business with happy customers (possibly on the back of the team's business/accounting/domain modeling expertise).
|
|
#
?
Oct 25, 2023 11:08
|
|
|
The largest user of Dyalog APL is SimCorp, who uses it for a portfolio management system. Dyalog cannot change the numerical behaviour of their primitives, even to improve them, because SimCorp's code may then change its valuation of some financial position. There may be business critical rounding errors here.
|
|
#
?
Oct 25, 2023 14:29
|
|
|
Svg (the vector image format) has basically the same texturing capabilities as ps1
|
|
#
?
Oct 25, 2023 16:02
|
|
|
redleader posted:langs shouldn't have built in number types at all. we tried this, it succ'd
|
|
#
?
Oct 25, 2023 18:02
|
|
|
tef posted:we tried this, it succ'd boo
|
|
#
?
Oct 25, 2023 18:17
|
|
|
tef posted:we tried this, it succ'd Nice!
|
|
#
?
Oct 25, 2023 19:22
|
|
|
tef posted:we tried this, it succ'd 
|
|
#
?
Oct 26, 2023 11:59
|
|
|
tef posted:we tried this, it succ'd
|
|
#
?
Oct 26, 2023 12:44
|
|
|
I've just encountered Frink, a lang that natively tracks units of measure with arbitrary precision, unit conversions, error bounds, etc. https://frinklang.org/#SampleCalculations I'm kinda charmed by it.
|
|
#
?
Nov 1, 2023 15:00
|
|
|
Is pi defined as exactly 3?
|
|
#
?
Nov 1, 2023 15:57
|
|
|
ynohtna posted:I've just encountered Frink, a lang that natively tracks units of measure with arbitrary precision, unit conversions, error bounds, etc. its unit definition file is pretty great https://frinklang.org/frinkdata/units.txt makes me laugh, makes me think
|
|
#
?
Nov 1, 2023 16:34
|
|
|
neat! ive been doing stuff with non-decimal currencies recently, its fun to play with unit systems
|
|
#
?
Nov 1, 2023 17:06
|
|
|
pokeyman posted:its unit definition file is pretty great https://frinklang.org/frinkdata/units.txt makes me laugh, makes me think this is a fun link, ty i enjoyed the  about the candela
|
|
#
?
Nov 1, 2023 18:53
|
|
|
I think the candela is a scam, and I am completely opposed to it. Some good-for-nothing lighting "engineers" or psychologists probably got this perceptually-rigged abomination into the whole otherwise scientific endeavor. What an unbelievably useless and stupid unit. Is light at 540.00000001 x 10^12 Hz (or any other frequency) zero candela? Is this expected to be an impulse function at this frequency? Oh, wait, the Heisenberg Uncertainty Principle makes this impossible. No mention for correction (ideally along the blackbody curve) for other wavelengths? drat you, 16th CGPM! drat you all to hell! Other bodies have attempted to define curves, often based on studies of human perception, to try and define the obvious deficiencies of this inadequate definition of the candela at anything more than this infinitesimal point. However, these are completely outside of any official SI definition, so no authoritative definition is possible. Bodies like the International Commission for Illumination (CIE) made an attempt with their various colorspaces, including "CIE 1931" and later versions that are more accurate but actually used less often. The most-commonly used, CIE 1931, is long known to be off by a factor of 7 from average human perception at short wavelengths, (compare it to the 1978 definition at 400 nm) and is arbitrarily truncated before the limits of human perception. In addition, no one perceptually-weighted curve is possible because the human eye is differently sensitive for photopic (bright-light, cone cells) and scotopic (dark-adapted, rod cells), or if the illumination occurs over narrower or wider fields. Many incremental improvements on these systems have been proposed, but none are part of the authoritative, oversimplified definition of the candela, making it useless for unambiguous definitions that can be agreed upon or binding to any party. Pronouncements of the CIE are in no way binding on the BIPM, nor vice-versa, and the CIE has a proliferation of "standard curves," which all disagree with each other. Agreements to use one curve or another thus have to be agreed *outside* the definitions of the SI, and, of course, parties can disagree on which curve to use. You can use CIE 1931, or CIE 1978, or the "CIE 1988 Modified 2° Spectral Luminous Efficiency Function for Photopic Vision" or the 2005 improvements by Sharpe, Stockman, Jagla & Jägle, or ISO 23539:2005(E), or something else... If you can point me to *anywhere* that the BIPM clearly mandates and defines a *single* luminosity function to unambiguously define the candela, please send it to me (eliasen@mindspring.com). Hint: they don't. You'll find that they all weasel out of an authoritative definition by saying "approved the use of" (usually multiple functions) or citing a couple of acceptable, non-agreeing options and saying one may be "preferred". If they define more than one allowed function, then there's obviously no single definition of "candela". If they're not absolutely clear whether you use the photopic or scotopic function, then they've defined two different candelas, which better be named different things. You can't have two different definitions of a meter, or a candela. And even the CIE notes that "for mesopic vision, there is at present no agreed method of weighting, but this problem is currently being investigated by the CIE." http://www.bipm.org/utils/en/pdf/Monographie1983-1.pdf What really annoys me is that the official definitions don't come right out and say, "okay, we're sorry, this is obviously a useless definition for any other wavelength, and it doesn't even make sense for *that* wavelength. We know. It sucks. The guys at the 16th CGPM went out and got drunk the night before instead of working on the definition, and they all sheepishly passed this in in the morning, and went back to bed. They got fired later, make no doubt. It's on our list of bugs. We're sending in the Wolf to fix it directly. Here is the workaround, but we consider it broken and we're ashamed to have ever put it forth in this useless form and left it this way for 30 years. For now, here is one single draft standard equation to use for other wavelengths. Download it here. We promise that the link works and contains a computer-readable table (though we're too sloppy to actually create a good smooth polynomial fit that would be a lot cleaner and easier for everyone) and is not some PDF of a terrible unreadable old re-scan, stashed away somewhere, making you wonder if it's valid today, nor is it a ridiculous CIE document that you have to *pay* a hundred bucks for, when we could and absolutely need to distribute it for free. "We've had the internet for weeks now. It represents our best effort and just has to go through a bunch of political committees but we promise that we'll try to keep it constant if possible." They never even *hint* with the definition that it's clearly insufficient, and obviously physically unrealizable in any way you look at it, which is what makes it so annoying. There's not even a "buy freaking CIE spec xxxyyy to get the rest of the details." Just nothing. Figure it out yourself. Update: On April 2, 2007, the BIPM and the CIE finally signed a vague agreement that they want to work more closely and hints at a future hope that there will someday be a single, authoritative definition accepted and mandated across both bodies. The agreement says that the expertise for defining a standard curve will fall under the auspices of the CIE, as "the CIE may decide to standardize." (No certainty nor timeline; just "maybe it'll happen someday.") Hopefully this will be followed by an official pronouncement of the BIPM that a certain curve is mandated for use in defining the candela. And hopefully it will be better than the old 1931 curve. And hopefully the BIPM will, you know, maybe PUBLISH it somewhere instead of pointing at the root of another web site and saying "it's one of the documents hidden somewhere over there but we're not going to tell you which and we want to see your face when you realize you have to buy random documents at a hundred dollars a pop." Don't hold your breath, though. It's been 30 years since the modern definition of the candela just to get to this point. See: http://www.bipm.org/utils/common/pdf/bipm-cie_agreement.pdf http://www.bipm.org/utils/en/pdf/SIApp2_cd_en.pdf The latter hints that perhaps one of the equations in CIE S 010/E:2004 (possibly superseded) / ISO 23539:2005(E) is maybe suggested by them, (but there are conflicting definitions therein, and none are mandated) and they're not going to help you find it, and when you do, you're going to realize that the CIE clowns are going to charge you over a hundred bucks for it. For something that needs to be free and accessible for anyone trying to understand this standard. We won't tell you if it's been superseded. We won't point you to an authoritative definition. We'll cite several equations and leave you to pick one randomly. We want this unit to remain an unusable mystery! In short, candela = EPIC FAIL. Update 2019: The official 2019 SI definition still refuses to acknowledge any of the above issues! "Hey, we fixed the SI but left this big useless definition in it just for fun."
|
|
#
?
Nov 1, 2023 19:50
|
|
|
still not sure what a candela is or isn't other than that it's stupid though
|
|
#
?
Nov 1, 2023 19:50
|
|
|
the hz rant is good too: Alan's Editorializing: Here is YET ANOTHER place where the SI made a really stupid definition. Let's follow their chain of definitions, shall we, and see how it leads to absolutely ridiculous results. The Hz is currently defined simply as inverse seconds. (1/s). See: https://physics.nist.gov/cuu/Units/units.html The base unit of frequency in the SI *used* to be "cycles per second". This was fine and good. However, in 1960, the BIPM made the change to make the fundamental unit of frequency to be "Hz" which they defined as inverse seconds (without qualification.) Then, in 1974, they changed the radian from its own base unit in the SI to be a dimensionless number, which it indeed is (it's a length divided by a length.) That change was correct and good in itself. However, the definition of the Hz was *not* corrected at the same time that the radian was changed. Thus, we have the conflicting SI definition of the radian as the dimensionless number 1 (without qualification) and Hz as 1/s. (Without qualification.) This means that, if you follow the rules of the SI, 1 Hz = 1/s = 1 radian/s which is simply inconsistent and violates basic ideas of sinusoidal motion, and is simply a stupid definition. The entire rest of the world, up until that point, knew that 1 Hz needs to be equal to *2 pi* radians/s or be changed to mean *cycles/second* for these to be reconcilable. If you use "Hz" to mean cycles/second, say, in sinusoidal motion, as the world has done for a century, know that the SI made all your calculations wrong. A couple of times, in different ways. This gives the wonderful situation that the SI's Hz-vs-radian/s definitions have meant completely different things in the timeperiods: * pre-1960 * 1960 to 1974 * post-1974 Thus, anyone trying to mix the SI definitions for Hz and angular frequencies (e.g. radians/s) will get utterly wrong answers that don't match basic mathematical reality, nor match any way that Hz was ever used for describing, say, sinusoidal motion. Beware the SI's broken definition of Hz. You should treat the radian as being correct, as a fundamental dimensionless property of the universe that falls out of pure math like the Taylor series for sin[x], and you should treat the Hz as being a fundamental property of incompetence by committee. One could consider the CGPM in 1960 to have made the original mistake, re-defining Hz in a way that did not reflect its meaning up to that point, or the CGPM in 1974 to have made the absolutely huge mistake that made the whole system inconsistent and wrong, and clearly broke the definition of Hz-vs-radian/s used everywhere in the world, turning it into a broken, self-contradictory mess that it is now. Either way, if I ever develop a time machine, I'm going to go back and knock both groups' heads together. At a frequency of about 1 Hz. Or better yet, strap them to a wheel and tell them I'm going to spin one group at a frequency of 1 Hz, and the other at 1 radian/s and let them try to figure out which one of those stupid inconsistent definitions means what. Hint: It'll depend on which time period I do it in, I guess, thanks to their useless inconsistent definition changes. It's as if this bunch of geniuses took a well-understood term like "day" and redefined it to mean "60 minutes". It simply breaks every historical use, and present use, and just causes confusion and a blatant source of error. Frink tries to follow the most authoritative international standards bodies for all of its definitions. However, when authoritative international standards bodies change definitions silently to make them inconsistent with their previous definitions and with centuries of fundamental mathematical definitions, then Frink would be negligent to not try to warn you of the huge incompatibilities in the strongest possible way. One of Frink's design goals is: "When in doubt, be pedantic. Explain to people how their calculation might be problematic and help them to write it in a more standardized, unambiguous way." The re-definition of the Hz is an actively damaging change that has to be warned about in the strongest possible terms. In summary: Frink grudgingly follows the SI's ridiculous, broken definition of "Hz". You should not use "Hz". The SI's definition of Hz should be considered harmful and broken. Instead, if you're talking about circular or sinusoidal motion, use terms like "cycles/sec" "revolutions/s", "rpm", "rps", "circle/min", etc. and Frink will do the right thing because it doesn't involve the stupid SI definition that doesn't match what any human knows about sinusoidal motion. WARNING: Use of "Hz" will cause communication problems, errors, and make one party or another look insane in the eyes of the other. In other words, if you use the Hz in the way it's currently defined by the SI, as equivalent to 1 radian/s, you can point to the SI definitions and prove that you follow their definitions precisely. And your physics teacher will *still* fail you and your clients will think you're completely incompetent because 1 Hz = 2 pi radians/s. And it has for centuries. You are both simultaneously both right and both wrong. You cannot win. You are perfectly right. You are perfectly wrong. You look dumb and unreasonable. The person arguing the opposite looks dumb and unreasonable. Hz == YOU CANNOT WIN (Insert "IT'S A TRAP" image here.)
|
|
#
?
Nov 1, 2023 19:56
|
|
|
pokeyman posted:its unit definition file is pretty great https://frinklang.org/frinkdata/units.txt makes me laugh, makes me think tag yourself, I'm // Miscellaneous ancient units
|
|
#
?
Nov 1, 2023 20:12
|
|
|
this is some quality stuff
|
|
#
?
Nov 1, 2023 21:32
|
|
|
More like CAN'Tdela
|
|
#
?
Nov 1, 2023 21:53
|
|
|
Plorkyeran posted:I think the candela is a scam, and I am completely opposed to it...
|
|
#
?
Nov 1, 2023 23:25
|
|
|
Presto posted:More like CAN'Tdela
|
|
#
?
Nov 1, 2023 23:45
|
|
|
pokeyman posted:its unit definition file is pretty great https://frinklang.org/frinkdata/units.txt makes me laugh, makes me think this is a good peruse
|
|
#
?
Nov 1, 2023 23:53
|
|
|
ynohtna posted:I've just encountered Frink, a lang that natively tracks units of measure with arbitrary precision, unit conversions, error bounds, etc. just implement units once in CLOS and have it interoperate with the rest of the Common Lisp world
|
|
#
?
Nov 4, 2023 10:57
|
|
|
the candela is trash to ease you in to the entire world of light measurement and colour reproduction being trash
|
|
#
?
Nov 4, 2023 11:06
|
|
|
common lisp interop is something to be taken care of just as soon as I finish tuning this 12 string guitar...
|
|
#
?
Nov 4, 2023 11:24
|
|
|
speaking of units i have a weird dream about adding fractions to my latex package and im scared of what its gonna do to my brain
|
|
#
?
Nov 4, 2023 13:27
|
|
|
Last time I tried to add a fraction to my latex package, I got part of a class-action lawsuit settlement against Enzyte
|
|
#
?
Nov 4, 2023 15:37
|
|
|
CPColin posted:Last time I tried to add a fraction to my latex package, I got part of a class-action lawsuit settlement against Enzyte fuckin lol
|
|
#
?
Nov 4, 2023 15:44
|
|
|
CPColin posted:Last time I tried to add a fraction to my latex package, I got part of a class-action lawsuit settlement against Enzyte looooooooool
|
|
#
?
Nov 4, 2023 15:49
|
|
|
"procs is a modern replacement for ps written in Rust" -rwxr-xr-x. 1 3,9M 4 nov. 21:09 output/target/usr/bin/procs So modernity is a binary of 3.9 MB for a "ps" replacement? I checked, and the .text section is indeed 3.2 MB Another one: "eza is a modern, maintained replacement for ls, built on exa" (in Rust) -rwxr-xr-x. 1,3M 4 nov. 21:57 output/target/usr/bin/eza 1.3 MB for ls! Double the size of a relatively featureful Busybox! The future. 
|
|
#
?
Nov 5, 2023 17:26
|
|
|
source your quotes
|
|
#
?
Nov 5, 2023 18:00
|
|
|
Achmed Jones posted:source your quotes irc.oftc.net #buildroot. Another Buildroot maintainer and myself.
|
|
#
?
Nov 5, 2023 18:04
|
|
|
hello world in c++ is two megabytes
|
|
#
?
Nov 5, 2023 18:08
|
|
|
Bloody posted:hello world in c++ is two megabytes 29000 times the size of the eicar test file smdh
|
|
#
?
Nov 5, 2023 18:14
|
|
|
|
| # ? May 26, 2024 16:46 |
|
|
Bloody posted:hello world in c++ is two megabytes Uh, no? C++ code:quote:g++ hello.cpp -o hello It's 17K with debugging symbols, 15K without.
|
|
#
?
Nov 5, 2023 18:21
|
|