Re: Beazley's Problem

2024-09-24 Thread Annada Behera via Python-list
-Original Message-
From: Paul Rubin 
Subject: Re: Beazley's Problem
Date: 09/24/2024 05:52:27 AM
Newsgroups: comp.lang.python

>> def f_prime(x: float) -> float:
>>     return 2*x
>
>You might enjoy implementing that with automatic differentiation (not
>to be confused with symbolic differentiation) instead.
>
>http://blog.sigfpe.com/2005/07/automatic-differentiation.html

Before I knew automatic differentiation, I thought neural networks
backpropagation was magic. Although coding up backward mode autodiff is
little trickier than forward mode autodiff.

(a) Forward-mode autodiff takes less space (just a dual component of
every input variable) but needs more time to compute. For any function:
f:R->R^m, forward mode can compute the derivates in O(m^0)=O(1) time,
but O(m) time for f:R^m->R.

(b) Reverse-mode autodiff requires you build a computation graph which
takes space but is faster. For function: f:R^m->R, they can run in
O(m^0)=O(1) time and vice versa ( O(m) time for f:R->R^m ).

Almost all neural network training these days use reverse-mode autodiff.


-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Beazley's Problem

2024-09-23 Thread Annada Behera via Python-list
The "next-level math trick" Newton-Raphson has nothing to do with
functional programming. I have written solvers in purely iterative
style. As far as I know, Newton-Raphson is the opposite of functional
programming as you iteratively solve for the root. Functional programming
is stateless where you are not allowed to store any state (current best
guess root).

-Original Message-
From: Paul Rubin 
Subject: Re: Beazley's Problem
Date: 09/22/2024 01:49:50 AM
Newsgroups: comp.lang.python

[email protected] (Stefan Ram) writes:
>   It's hella rad to see you bust out those "next-level math tricks"
>   with just a single line each!

You might like:

https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf

The numerics stuff starts on page 9.


-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Drop into REPL when your program crashes.

2025-09-10 Thread Annada Behera via Python-list
So, ipdb is the ipython version of pdb. In fact, post_mortem is a
pdb function. I use ipdb because its REPL is a bit nicer to work
with then pdb.

-Original Message-
From: Stefan Ram 
Subject: Re: Drop into REPL when your program crashes.
Date: 09/08/2025 06:04:16 PM
Newsgroups: comp.lang.python

Annada Behera  wrote or quoted:
> Recently I have been increasingly adding this piece of code as
> a preamble to a lot of my code.
> 
>    import (sys, os, ipdb)
> 
>    def debug_hook(exc_type, exc_value, traceback):
>    if exc_type is KeyboardInterrupt:
>    sys.__excepthook__(exc_type, exc_value, traceback)
>    return
>    print(f"Uncaught exception: {exc_type.__name__}: {exc_value}")
>    ipdb.post_mortem(traceback)
> 
>    if os.environ.get('DEBUG'): sys.excepthook = debug_hook

  Thanks! 

  I have changed it a bit to work without "ipdb" and added demo code.

import sys
import os
import pdb

i = 1

def debug_exception_hook(exc_type, exc_value, tb):
    i = 2
    if issubclass(exc_type, KeyboardInterrupt):
    # Call the default excepthook for KeyboardInterrupt to allow
clean exit
    sys.__excepthook__(exc_type, exc_value, tb)
    return
    print(f"Uncaught exception: {exc_type.__name__}: {exc_value}")
    pdb.post_mortem(tb)

def cause_exception():
    # Function to demonstrate an unhandled exception
    i = 3
    return 1 / 0  # Will raise ZeroDivisionError

def f():
    # Function to demonstrate an unhandled exception
    i = 4
    cause_exception()
    return i

if __name__ == "__main__": # demo code
    import os; os.environ['DEBUG'] = 'true'

    if os.environ.get('DEBUG'):
    sys.excepthook = debug_exception_hook
    print("Debug mode enabled: Using pdb post-mortem on uncaught
exceptions.")
    else:
    print("Debug mode not enabled: Regular exception handling.")
    
    # Run demo to trigger exception
    i = 5
    f()

  Then, I got this dialog:

Debug mode enabled: Using pdb post-mortem on uncaught exceptions.
Uncaught exception: ZeroDivisionError: division by zero
> debug_hook.py(19)cause_exception()
-> return 1 / 0  # Will raise ZeroDivisionError
(Pdb) i
3
(Pdb) 

  .

-- 
https://mail.python.org/mailman3//lists/python-list.python.org


Drop into REPL when your program crashes.

2025-09-10 Thread Annada Behera via Python-list
Hi,

Recently I have been increasingly adding this piece of code as
a preamble to a lot of my code.

import (sys, os, ipdb)

def debug_hook(exc_type, exc_value, traceback):
if exc_type is KeyboardInterrupt:
sys.__excepthook__(exc_type, exc_value, traceback)
return
print(f"Uncaught exception: {exc_type.__name__}: {exc_value}")
ipdb.post_mortem(traceback)

if os.environ.get('DEBUG'): sys.excepthook = debug_hook

This has been extemely helpful when debugging and even in prod. When
degugging, this helps me go up and down my backtrace like I am in gdb.
In fact, it is better than gdb. I can use evaluate any python expression
directly, and verify the shape of my tensors and exactly what caused
the error. It's like freezing the entire program right at the time the
program failed. This way I don't have to second guess what exactly
failed in the entire training loop and the next time I can fix it.

if True or os.environ.get('DEBUG'): sys.excepthook = debug_hook

Even when not debugging, it helps me salvage the results if a 3 week
running experiment fails at 90% completion.

Annada
-- 
https://mail.python.org/mailman3//lists/python-list.python.org