News for hackers. Stuff that matters.
Re:1/0 = 0 (2018) by throwawaymaths on Monday December 02, 2024 @12:24AM (#42293375)
1/0 = 0 is usually not a practical thing, it's to satisfy that the output of the division operator stays in the type and you don't want crashes (a "feature" of ponylang and gleam, e.g.). Its kind of a PL wonk thing.

It's not at all a good idea for very important practical reasons as I outline in a reply to parent.

Re:1/0 = 0 (2018) by ncruces on Monday December 02, 2024 @02:35AM (#42293939)
I don't want to handle errors after every division and division doesn't crash, both sound rather practical, though.
Re:1/0 = 0 (2018) by AlotOfReading on Monday December 02, 2024 @03:23AM (#42294224)
The original purpose of defining it to be Nan/INF in floating point was exactly that. You'd do all the work and then check if it was Nan/INF at the end without having to check every intermediate result.
Re:1/0 = 0 (2018) by eru on Monday December 02, 2024 @06:34AM (#42295176)
If you want to do all the work at the end, 'exceptions' do exactly that, too.
Re:1/0 = 0 (2018) by davorak on Monday December 02, 2024 @12:37PM (#42298385)
Throwing an exception in a function normally stops the rest of the work that function would do. That is not the case when using Inf and similar

    > const f = (x) => [x/2, x/0]
    undefined
    > f(10)
    [ 5, Infinity ]
Re:1/0 = 0 (2018) by NBJack on Monday December 02, 2024 @01:38PM (#42298966)
I assert stopping immediately is much more practical. In many cases, you waste considerable amounts of processing power to reach a conclusion you often won't be able to use.
Re:1/0 = 0 (2018) by eru on Monday December 02, 2024 @11:50PM (#42303154)
It depends on your use case.
Re:1/0 = 0 (2018) by throwawaymaths on Tuesday December 03, 2024 @10:27PM (#42314248)
Sure but what should be the default?
Re:1/0 = 0 (2018) by eru on Wednesday December 04, 2024 @02:00AM (#42315073)
Rust and Haskell can solve this fairly well: both styles of dealing with errors are easily accessible.

Go solves this really badly.

As for specifically what to do about division: the right default depends on your application. Either way is defensible, and I would rather work on making it easy to pick either style in the language of your choice, than to worry too much about what the default should be.

Re:1/0 = 0 (2018) by eru on Monday December 02, 2024 @11:50PM (#42303155)
That's a good point, sometimes this is what you want.
Re:1/0 = 0 (2018) by Cpoll on Monday December 02, 2024 @04:38PM (#42300694)
The problem is that if you forget to check you find out a month later or ten functions over.
Re:1/0 = 0 (2018) by throwawaymaths on Monday December 02, 2024 @04:38PM (#42300698)
> I don't want to handle errors after every division and division doesn't crash.

You can have one or the other.

You can't have both without the risk of nasal demons. Unless the result of the operation is business-safe to throw away.

That's why having the default / have both is an poor design choice by gleam and pony. Someone will reach for / and encounter demons. Afaict the other langs that do this are not intended for real world prod use. By default / should force the developer into either crashable or unwrap error return. If you want some sort of opt-in "logic-unsafe /", fine but call it something else like </> e.g.

Re:1/0 = 0 (2018) by cassepipe on Monday December 02, 2024 @02:31PM (#42299500)
Funny you should mention gleam since it's a BEAM host language... surely they shouldn't fear crash management, right ?
Re:1/0 = 0 (2018) by throwawaymaths on Monday December 02, 2024 @04:19PM (#42300519)
You would think.

Some people get scarred working in other langs and can't let go, I guess?

Re:1/0 = 0 (2018) by IIAOPSW on Tuesday December 03, 2024 @12:28PM (#42308675)
Well, if the requirement is to stay in the type, you could extend the type to include the point at infinity. That satisfies both programmer and the mathematician.

https://en.wikipedia.org/wiki/Projectively_extended_real_lin...