Yuck. Division by zero is an unfortunate reality but basically nobody with mathematical background thinks that just defining x/0 = 0 is a good solution.
Often in numerical computing, getting an NaN or Inf is a blessing in that it’s a hint that your algorithm is numerically buggy, in the same way that a crash or a exception would indicate a program bug.
This approach is the numeric equivalent of a program continuing on after an undefined variable, just assuming it’s 0. That was tried by scripting languages in the 90s and these days most folks think it was a bad approach.
The divide-by-zero thing is explained here[1]. The relevant bits:
> Gleam does not implicitly throw exceptions, so throwing an exception is not an option. The BEAM VM does not have a Infinity value, so that is not an option. Therefore Gleam returns 0 when dividing by zero.
> The standard library provides functions which return a Result type for division by zero which you can use if that is more suitable for your program.
You can also use Guards[2] to prevent handle a divide-by-zero situation before you attempt it.
I know you are quoting the docs, but Gleam absolutely throws implicit exceptions, for exactly the same reason why it returns 0 when dividing: the Erlang/VM does not support Infinity/NaN, which means floating point operations can also overflow/underflow. For example, any division with a subnormal will raise:
1.0 /. 5.0e-324
Or addition between really large floats:
1.0e308 +. 1.0e308
In fact, even the `float.divide` function, which is meant to be safe, will raise:
float.divide(1.0, 5.0e-324)
In other words, most functions that returns floats have an unmapped codomain and because of how floats work, and it is not simply a matter of checking if one of the inputs is equal to 0.0.
If Gleam wants to be consistent with division, all float operations would have to return a `Result` type (which I assume would have a direct impact in both performance and user convenience). Plus `let assert` provides a hatch for any function to raise too, and that includes matching on unmapped floats:
let assert <<a:float>> = <<0x7FF0000000000000:64>>
I wouldn't call myself a person with a mathematical background, but there are those people who believe it's just fine. [0] I don't have enough knowledge to debate that, but it would seem to disprove "basically nobody". Zero is a convention, like NaN or Inf are conventions.
A problem that Gleam has here is that the Erlang runtime does not have NaN or Inf in its float type (or integer type for that matter). It could be represented with an atom, but that would require an atom and a float having the same type in Gleam, which is not something the type system can do (by design). The operator could, in theory, return a Result(Float, DivisionByZeroError), but that would make using it very inconvenient. Thus zero was chosen, and there is an equivalent function in the stdlib that returns a result instead, if you wish to check for division by zero.
> but there are those people who believe it's just fine. [0]
Just fine mathematically, but Hillel does specify that he's not comfortable with the concept from a safety perspective. The whole piece is a defence against a particular type of criticism, but he leaves wide open the question of whether it's a good idea from a PL perspective.
I have no math background but every line of code I wrote that involved a division, I just wished that division by 0 results in 0, so this actually resonated with me
Because "0" often means "show none", so when dividing by 0, I'm fine "showing none".
I'm sure it doesn't work for everybody, but I never had a specific need to deal with zero in the division that didn't result with "actually let's count it as 0"
There are several domains where 0 is different from none, for example, most computations involving rates.
Imagine that you are running some A/B tests and you want to track conversions. If one of the experiments received 10 users and had 5 conversions, you want to show 50%. If it received 10 users and had no conversions, you will show 0%.
However, if it has received 0 users, while you could show zero conversions, the correct answer is to say that you don't know the conversion rate. Because maybe, if you had had 10 users, they could have all converted, and the rate would be 100%. You simply don't know.
Same logic applies over computing ROI, interest, velocity, etc.
Agree, I'm not saying there aren't counter examples, I'm just stating that making the call of returning zero when dividing by zero it's not an insane call, there are valid reasons for doing that. It's a judgement call (and they do provide a function that does the right thing)
> In python for instance, the developer needs to be prepared to catch a divide by zero exception.
> In gleam, the same consideration is required but the implementation will just differ.
These aren't remotely the same. If a developer fails to catch an exception or a NaN then the program either crashes or returns an obviously wrong result. If a developer fails to guard against a zero returned from division then they get a number out that's wrong in subtle ways that may not be obvious until the wrong numbers are already in use somehow.
The question isn't whether you can work around the error, it's how likely you are to notice that you screwed something up before it's too late.
In Python and languages with similar behavior, a division by 0 will immediately crash your program with a pretty stack trace, showing you exactly where the problem is and how the program got there.
In languages where division by 0 produces infinity, NaN, 0 or similar, your calculation just returns a nonsensical result.
Zero is even worse than inf or NaN, as you may not even realize that there was an error in the first place, as the result of your calculation is a number and not a strange-looking value.
Defining x/0 as 0 doesn’t break anything mathematically; all the relevant field axioms have an x != 0 hypothesis so this really is undefined behavior.
Moreover, it’s actually pretty common for proof assistants to adopt the x/0 = 0 convention, as it turns a partial function into a total one! Having something like NaN or Inf is definitely a better solution in practice, but x/0 = 0 does have its merits!
Yeah you can really get yourself into trouble if you make dividing by zero zero. It's a strong indication that you have done something horribly wrong in your code upstream of that point. Why would you throw away that signal?
A biography of Dr Paul Farmer and how he dedicated his life and sacrificed everything to solve (in his words) “easily preventable” health problems in Haiti.
It hits on many levels: his unapologetic empathy for ordinary people, the global abuse and abandonment of Haiti by western powers, the flaws of thinking about global health through a lens of utilitarianism, the real change that just one person can initiate, etc
I decided on using sigils and then my thought-process drifted to Perl/Php, so $ naturally felt like a variable definition (which naturally must pop from the stack). I guess ^ is “push ‘up’ to stack”. But it’s all really arbitrary irrelevant syntax. YMMV.
Thanks for the kind words. But if you’re looking for fancy data-structures, you won’t find them. Haha. It’s just a single object type (sum-type/tagged-union) and lots of cons cells. In other words, just a minimalist Lisp.
Subtly different. Originally I didn’t have ^a, but you do in-fact need it. ^a means “push with no evaluation” and (a) means “build a closure” that computes a”.
If you push, pop, push, pop, push repeatedly you’ll be wrapping the value in lots of closures. The value is no longer a value too. You’d have to “force” it to get back the value.
Semantically quite different. If you’re going all Turing tarpit, could you survive without “^a”? Maybe. But you’d be suffering for sure.
Operationally, you don't have to do the wrapping: since (a) is equivalent to ^a, you can substitute the implementation of the latter when you see the former.
Though if `(a)` is observably "no longer a value" of course then that's an issue. Which may or may not be a problem :-)
I thought of that. But then you’re making the semantics complicated. Say you really did want a (a) closure. Now you can’t have one, and you have to resort to more tricky wrapping. Not worth it.
Division is much harder, but doable also. Generally Forsp in the camp of minimalist languages so minimizing the number of primitives seemed more interesting.
If you want to play around yourself, it’s trivial to add those operations.
Also thanks for sharing; looks interesting. I’ll read this when I have time and re-comment then. Off the bat: Forsp variables are definitely not linear.
First HP engineers made RPL, then they attended Sussman and Abelson's intro to CS class. I think Sussman once said that, if RPL had anonymous functions it'd be a perfect lisp.
Right there in our Lord's prayer is some financial advice:
> And forgive us our debts,
as we also have forgiven our debtors.
In the original Greek of Matthew's prayer, the word is "ophelilema", as in financial debt. There are other words for more metaphorical debts like when breaking rules, which were notably not used.
Akhshually Jesus would have been speaking Aramaic. So even if Matthew wrote his Gospel in Greek it may not necessarily be the most accurate translation of what Jesus actually said. /end pedantry
In any case, the "gospel of prosperity" types in Christianity are second only to the "secretly a sex pest" types in regards to how obnoxious they are and how much of a black eye they give to Christianity's reputation.
> Akhshually Jesus would have been speaking Aramaic.
Actually, like most people in the world, and especially people in "border lands", if he existed, he probably will have been multilingual. Aramaic for sure, but he might also have spoken some Hebrew, Greek and maybe even Latin.
Sure. But if you claim to follow the man, it means following the book, and the book is - once again - very clear on certain topics, regardless of who put the words down.
There’s a very big difference between being a Christian and preaching to the world about it constantly. Out of the 2.4 billion only a fraction insist on letting you know it in everything they do.
Well it depends on whether you consider everyone that claims to be or is assumed to be by default, a Christian, and what exactly you mean by “constantly.”
A true Christian will by definition be preaching the gospel to the lost and dying world at every opportunity
Usually people use words so that other people will understand them. If your internal definition doesn't match nearly anyone else's, maybe you're using the word wrong.
Isn't that all language is? An appeal to what others think you mean? This ofc is why people like to push definitions in different directions. I think you're saying, "Christian should mean XYZ," while I'm pointing out most people don't hold your meaning. If you want everyone to adopt your definition, you need to give a compelling reason. However, I've heard so many other people who call themselves Christian claim that all the other so-called Christians are not really Christian, that I don't really trust any particular Christian's definition. It's easier to just say, "Christian means someone who claims to be Christian".
That's because the "prosperity gospel" faction (also called "pray and display" and "gab and grab") is so very open about money and the good life, it's in fact their core part of religious practice.
When a regular person says "heaven has blessed me with this and that", that's making a statement of fact, that person says he has this and that and he credits the deity, nothing more. But when a prosperity gospel guy says such, that person is engaging in theurgy. He believes that the deity blessed him in such and such a manner and by publicising the fact the deity must necessarily bless him with much much more money.
Positive thinking and "law of attraction" is less overtly Christian but made from the same cloth and just as detestable.
If you find that theology distasteful, childish or blasphemous you are not alone.
Probably because if you're actually into Jesus, as in, what is taught by him in the Bible and not the bastardized evangelical prosperity gospel white Jesus that Americans are into, you wouldn't really seek out money apart from having enough to live on.
Also worth noting that being active in an organization like a church provides one with a sizable community of people, many of whom are probably at least doing okay, and depending which church, can be quite wealthy and they will automatically find you more trustworthy because you are in "their group," so fraud is baseline easier to execute. And, in the odd event you are caught out, a well performed "reformation" will have you as a in-good-standing member of that community again, and probably benefiting from the charity of it's members in short order.
This is a big part of why MLM/pyramid schemes, the Mormons, and the state of Utah are so deeply intertwined.
And I mean, let's not leave out the obvious one: people big on magical thinking aren't generally the best at critical thinking.
This is not to say that religious people are the only ones who can be scammed, that's of course nonsense. But people who believe things like "god has a plan" and indulge in the just world fallacy freely and "everything happens for a reason" are on balance just plain easier to manipulate, and even if as that one quoted pastor says, that Hwang is a true believer, well that could just mean he believes his schemes are god's plan, that his actions are god's creation, that what he has done is what he was put on this earth to do, and all that. He could be a swindling liar or a true believer, it doesn't matter. How many people have done diabolical things in our history believing whatever deity they believe in had created them to do it? It's just motivated reasoning. You believe in a just and mighty god, and you have ideas for how to do anything, steal from people, amass wealth, harm people, whatever, and it just so happens that you find all the passages from your god that cosign what it is you already wanted to do? No kiddin, weird how that always works out.
i prefer calling up clergy and asking them when i have questions of this sort. I'm non-religious but in order to talk about it respectfully i sometimes have questions.
(disclaimer: I'm an atheist American who was raised sort of "Christian by default" but whose immediate family virtually never attended church and never identified with any particular denomination)
I'd guess at some social function of the equalizing narrative of universal/original sin and Jesus being the scapegoat for it. Being highly reductive about it, I can imagine the prosocial lens and the antisocial one.
Through the prosocial lens, it says that we must all be humble regardless of our propriety or material accomplishments, because even the greatest and purest of us are not above sin. We must respect the struggle of our fellow fallen man against the unrelenting pull of temptation to commit transgressions, and remind ourselves to demonstrate Christlike mercy when they fail.
Through the antisocial lens, it says that you might as well lie/cheat/plunder/exploit/murder and beg for forgiveness if you're caught, because you're considered tainted in either case. In an odd way, the stereotypical evangelical redemption/rebirth narrative arguably values greater sins more than lesser ones: "if the blood of the Lamb can cleanse this sin from me, then your salvation is certain".
// Division by zero is not an error
io.debug(3.14 /. 0.0)
It prints 0
Yuck. Division by zero is an unfortunate reality but basically nobody with mathematical background thinks that just defining x/0 = 0 is a good solution.
Often in numerical computing, getting an NaN or Inf is a blessing in that it’s a hint that your algorithm is numerically buggy, in the same way that a crash or a exception would indicate a program bug.
This approach is the numeric equivalent of a program continuing on after an undefined variable, just assuming it’s 0. That was tried by scripting languages in the 90s and these days most folks think it was a bad approach.
reply